feat: log which MCP client connected, fix missing logging capability - #43
Merged
Conversation
Two fixes in the same startup path:
1. The McpServer never declared the logging capability, so every
sendLoggingMessage call (including the existing startup/shutdown/fatal
error messages) was a silent no-op regardless of when it was sent.
Declared logging: {} in capabilities.
2. server.server.getClientVersion() is only populated once the client's
initialize request has been processed -- reading it synchronously right
after server.connect() races that request, since connect() only waits
for the transport to start, not for the handshake to finish. Moved the
read into a server.server.oninitialized callback, which fires only once
the handshake is fully done.
The client's identity (name/version from its initialize request) is now
logged on connect and recorded as mcp.client.name/mcp.client.version on
every subsequent tool-execution trace span, matching the equivalent
changes in @mapbox/mcp-server and @mapbox/mcp-devkit-server.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
zmofei
approved these changes
Aug 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two fixes in the same startup path:
McpServernever declared theloggingcapability, so everysendLoggingMessagecall — including the existing "server started" / "shutting down" / "Fatal error" messages — was a silent no-op regardless of when it was sent. Declaredlogging: {}in the server's capabilities.server.server.getClientVersion()is only populated once the client'sinitializerequest has been processed. Reading it synchronously right afterserver.connect()races that request, sinceconnect()only waits for the transport to start, not for the handshake to finish. Moved the read into aserver.server.oninitializedcallback, which only fires once the handshake is fully done.The client's identity (name/version from its
initializerequest) is now logged on connect, e.g.Client identified as: claude-ai v1.0.0, and recorded asmcp.client.name/mcp.client.versionon every subsequent tool-execution trace span (withToolSpan), so OTel-backed traces can be filtered or grouped by client. Matches the equivalent changes landing in@mapbox/mcp-server(#253) and@mapbox/mcp-devkit-server(#139).Test plan
test/utils/tracing.test.ts) coverwithToolSpanpicking upmcp.client.name/mcp.client.versiononcesetClientInfois callednpx vitest run— all 85 tests passnpm run buildsucceedsMapbox Documentation MCP Server v0.3.1 startedandClient identified as: pretend-vscode-client v2.1.0(previously neither message reached the client at all, sinceloggingwasn't declared)🤖 Generated with Claude Code